The activity of debugging data processing systems is akin to diagnosing problems in such systems. A first class of debugging tools primarily help diagnose bugs by allowing the computer programmer to halt the execution of a sequence of instructions on a central processing unit (CPU). This debugging technique is commonly known as ‘setting an instruction breakpoint’. It relies on support in the CPU and is generally available on modern processors.
Another type of debugging facility supported by modern processors is the ability to ‘set a hardware data breakpoint’. In such a debugging technique, access to a memory location is detected. Setting hardware data breakpoints is available in some modern processors and the technique also requires support by the CPU. More specifically, in this case, the CPU monitors all accesses to memory and compares them to desired data breakpoint locations kept in debug address registers. When there is a match, the CPU halts, allowing the computer programmer to inspect the state of the machine. In using this technique, there is a limitation to the number of memory locations that can be monitored simultaneously. For example, in the Intel Pentium 4 processor, only four 32 bit sized locations can be monitored simultaneously.
3rd generation language constructs such as ‘C’, Java, and ‘C++’ constructs are translated into a combination of instruction sequences and data structures. Debugging the output of these languages relies primarily on verifying the correct sequence of instruction is executed. Instruction breakpoints aid in this process by stopping the CPU at designated points in the control flow sequence. Data breakpoints are less frequently used, but are useful as well to detect reads and writes to data structures. Whereas there is no limit to the number of instruction breakpoints that can be set, there is only a limited number of data breakpoints that can be set on modern CPUs.
Unlike 3rd generation language constructs, some state-machines and language constructs have their control flow translated only into data structures, rather than into instruction sequences. As an example, RTExec, part of the RTEdge platform, is a toolset used in describing such state-machines or language constructs. Instruction breakpoints are not as useful for debugging such language constructs since there is no instruction sequence to interrupt. Setting data breakpoints is therefore more important for debugging these language constructs. Efficient methods and systems of setting data breakpoint are desired.